home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 1053 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.4 KB
  1. Date: Mon, 21 Feb 1994 02:18:15 -0500
  2. From: "Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>
  3. To: reschke@GOEDEL.UNI-MUENSTER.DE
  4. In-Reply-To: Julian Reschke's message of Sun, 20 Feb 94 16:56:56 MET DST <9402201556.AA12620@math.uni-muenster.de>
  5. Subject: TOSFS
  6.  
  7. >Being at it, I made tos_getxattr return correkt values for block size and
  8. >number of blocks (for files). Also, I've implemented a new scheme for
  9. >computing something more sensible for the inode: I'm doing a 32-Bit-CRC
  10. >over the full pathname. At least I get the same inode for multiple stat()'s
  11. >to one file, and all inodes *seem* to be unique on my filesystem. Of course,
  12. >that can't be guaranteed... Drawback: the CRC table takes 1K of memory.
  13. >What do you think?
  14.  
  15. I've been thinking of a scheme like this for a while, but decided it
  16. wasn't worth implementing unless the inode could be guaranteed unique
  17. instead of just "usually" unique.  However what you've written would
  18. definitely be preferable to the currently implemented method of making
  19. up inodes.
  20.  
  21. My feeling is that the best inode computation would be to use the
  22. starting sector number of the file as the inode.  But I don't know of
  23. a way to compute the starting sector number without reading the FAT
  24. directly.
  25.  
  26. cheers,
  27. entropy
  28.  
  29. --
  30. entropy -- it's not just a good idea, it's the second law.
  31. Personal mail:      entropy@gnu.ai.mit.edu
  32. MiNT library mail:  entropy@terminator.rs.itd.umich.edu
  33. "what do you have against octal?" -jrb
  34.  
  35.